Subject: SIDL=SIDH=0, ODAI=?? Mutual ACTPU

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Fri, 18 Mar 94 08:16:22 EST

Ref:    Dave Finnie's note

It sounds kind of kinky: adjacent nodes both contain SSCP support and
both contain dependent LUs - so they both ACTPU each other and support
each other's dependent LUs!  While this is totally outside the realm of
my experience, it sounds architecturally permissible.  Thanks for
calling it to our attention, Dave.  Before anybody takes a firm position
on this, I have a few questions for you.

(1) What happens with NMVTs, RECFMS, REQFMS and other management stuff
    that flows on the SSCP-PU session?  If I send mine to you and you
    send yours to me, how do we each get managed?

(2) What happens if you introduce DLUR(s) and DLUS(s) into the picture?
    Is it possible to end up with TWO DLUR pipes providing SSCP support
    in opposite directions? (mirror mirror on the wall)

(3) Could you describe the configuration where adjacent nodes both
    require SSCP support from each other in more detail?  What is the
    customer trying to accomplish with this configuration?

I'd like to see reasonable answers to those questions before the
Reference SIG debates whether the proposed architecture clarification
adds an unnecessary restriction -- or whether InSession's and similar
implementations should be considered a deviation.

     Marcia
_________________________________________________________________________
 Marcia L. Peters                           mpeters @ ralvm6.vnet.ibm.com
 Advanced Peer-to-Peer Networking           VNET:       MPETERS at RALVM6
 IBM Corp.
 Research Triangle Park, NC 27709           Telephone:     (919) 254-4380

---

From: [email-masked] (Dave Finnie)
Date: Mon, 21 Mar 94 11:10:18 EST

Marcia,

>     send yours to me, how do we each get managed?

You are right in that these management services flows are free to go
in both directions. I don't believe this causes a problem in terms of
how things get managed. Since both nodes are privy to alert information, etc
of their partners, then either (or both) can be used for monitoring the
status of the network. This is a purely customer based decision, since,
if they choose, they could simply ignore the management data flowing into
one of the nodes.

>     in opposite directions? (mirror mirror on the wall)

Yes, it would seem that it is possible for this to happen. I can't think of
any inherent technical problems that can be associated with it, since the
DLUR/DLUS sessions are simply APPC sessions.

>     customer trying to accomplish with this configuration?

We are using this method to propagate "logons" over NT 2.1 links, in a 
manner similar to that used in OS/400 R2.3. The difference is that in
our node, we allow both primary and secondary non-APPC LUs to use NT 2.1
links, and hence we require logons to be able to flow in both directions.
While this functionality will eventually be replaced by SSE when and if
it becomes available, we have requirements to offer the functionality
now, and our previous implementation of passing logon requests had
several flaws, which this method resolves. The use of dependent LUs also
allows us to share printers with applications in other nodes, and hence
for this sharing to be possible in both directions, we require 
dependent LUs to exist in both directions.

The other point I would like to make here is that, although what I have
proposed is perhaps an exotic use of the architecture, there is no
fundamental reason why the architecture should *limit* the things that
implementations can offer using it. This is especially true when it
is very logical to extend the bi-directional nature of NT 2.1 FID2
addressing into the realm of dependent LU sessions. Restricting such
sessions to one direction only is simply adding an extra rule that doesn't
need to be there.

regards,

Dave